Method for executing trusted-path commands

ABSTRACT

A method for executing trusted commands, in which a trusted command is first received from a user at a user terminal and parsed by untrusted code; then passed to a trusted computing base for execution. The trusted computing base displays some indication of what is to be done back to the user for confirmation. Confirmation of the commands prevents unauthorized modification of the commands and increases system confidence. A randomly (or pseudo-randomly) generated process identifier is employed to verify the existence of a trusted path.

1. BACKGROUND OF THE INVENTION

1.1 Introduction

This invention relates to a method for improving security in a computersystem. More specifically, this invention concerns a method forimplementing trusted commands through both trusted and untrusted code.

1.2 Background

The proliferation of computers has resulted in the need for reliablecomputer security systems. The need to protect certain information isgreat in areas dealing with national security, for example. Securitymeasures are required in other fields, including areas which utilizefinancial, medical and personal information. Many computerizedinformation systems therefore include internal security measures whichprovide the users with different levels of access to the computerizedinformation, and which attempt to provide at least a degree ofprotection of the information from undesirable access.

1.3 Security Criteria: Reference Validation Systems

In response to the need for secure computer systems, the Department ofDefense has issued a publication titled Department of Defense TrustedComputer System Evaluation Criteria (reference No. DOD 5200.28-STD).This publication is sometimes referred to as the “Orange Book,” and isavailable from the Department of Defense. The Orange Book describessystem security objectives and evaluation criteria for secure computersystems.

A “secure” computer system generally includes some type of “referencevalidation” system. These reference validation systems (known asreference monitors) are responsible for enforcing the security rules(security policy) for a given computer system.

Reference monitors mediate all access to “objects” by “subjects”.Objects are passive entities that contain or receive information. Accessto an object implies access to the information that it contains.Subjects are active entities, generally in the form of a person, processor device that cause information to flow among objects or change thesystem state. A subject may ordinarily reference its own,subject-internal information without the involvement of the referencemonitor. Reference monitors controlling such access to objects bysubjects are known in the art, and may utilize a security kernelapproach.

Proper implementation of a reference monitor calls for adherence tothree principles:

-   -   (1) completeness, in that all access by subjects to objects or        other subjects must involve the monitor;    -   (2) isolation, in that the monitor must be protected from        tampering; and    -   (3) verifiability, in that correspondence must be shown between        the security policy and the actual implementation of the        monitor.

As discussed, every reference to information or change of authorizationshould go through the reference monitor. Thus, all commands issued by auser or other subject arc monitored by the reference monitor. Thisapproach is particularly useful in multiuser computer environments.

The totality of the protection mechanisms within a computersystem—including hardware, software, and firmware, the combination ofwhich is responsible for enforcing a security policy—is commonly knownas a “trusted computing base” (TCB). If the trusted software is designedto be as simple as possible, for the sake of verifying the referencemonitor, then the trusted software is known as a “security kernel”.

Generally, TCBs attempt to meet the control objectives set out in theOrange Book. Compliance with these objectives inspires user confidence,and increases the overall desirability of a computer system. Theseobjectives deal with:

-   -   (1) security policy;    -   (2) accountability; and    -   (3) assurance.

The security policy objective entails enforcement by the TCB of thedesired security rules. These security rules are designed to limit theaccess to and dissemination of information in a precisely definedmanner.

Security policies may include provisions for the enforcement of bothmandatory and discretionary access control rules. Mandatory accesscontrol rules control access based directly on comparisons of the user'ssecurity level and the sensitivity level of the information beingsought. Discretionary access rules control and limit access toidentified individuals who have been determined to have a need-to-know.

These access control rules call for associating with each useridentification code a statement indicating the user's access rights.This statement often includes information representing the user'ssecurity level (for mandatory control purposes), and membership ingroups (for discretionary control purposes).

The accountability objective calls for providing each user with anindividual user identification code (often called a “user name”) and forthe TCB to be able to recognize the code and ensure that it is beingused by its proper user. This may be done by checking the user'spassword. This ensuring the user's identity is known as“authentication”.

In addition, the accountability requirement calls for the existence ofauditing capabilities. Such capabilities allow for the auditing ofactions which can cause access to, generation of, or release ofclassified or sensitive information.

1.4 Assurance Objectives and “Trusted” Systems

The assurance objective is especially important in the present context.That objective is concerned with taking steps to ensure that thesecurity policy is correctly implemented and that the TCB accuratelymediates and enforces the intent of that policy. Steps may be taken toinsure that each portion of the TCB is assured. To accomplish thisobjective, two types of assurance are needed.

The first type of assurance is life-cycle assurance. This type ofassurance refers to steps taken to ensure that the computer system isdesigned, developed, and maintained using formalized and rigorouscontrol standards.

The second type of assurance is operational assurance. Operationalassurance deals with the features and system architecture used to ensurethat the security policy is uncircumventably enforced during systemoperation. All of the software (sometimes referred to informally in theart as “code”) in the TCB is generally analyzed to determine theassurance level of the system.

As the amount of code in the TCB increases, it becomes more difficult toensure that the TCB accurately enforces the security policy. Because ofthis, it is desirable to minimize the amount of trusted code, and thusthe complexity of the TCB.

A TCB is usually operated with a substantial amount of software, such astext editors and other applications, operating within the securitypolicy of the TCB. Generally, this untrusted software asks the TCB foraccess to objects when the user or the untrusted software requires them.Thus, the majority of user's requests to the TCB, and the majority ofthe information that a user obtains from the TCB, are handled throughthe agency of untrusted software.

This untrusted software, however, is by nature in danger of compromiseand vulnerable to bugs. For some types of requests and displays,malicious or malfunctioning untrusted software could compromise theenforcement of the security policy. Generally, TCBs cannot distinguishbetween requests faithfully made by the untrusted software on commandfrom a user and either requests made by the untrusted software at itsown initiative or requests that misrepresent the user's actual command.For example, if commands issued by an authorized user to change certainusers' security levels were made through the agency of untrustedsoftware, it would be possible for malicious or malfunctioning untrustedsoftware to inappropriately raise the security level of a user. Suchinappropriate raising of a security level could result in the disclosureof sensitive information.

Furthermore, TCBs generally cannot ensure that displays made byuntrusted software arc faithful. This poses problems in that if displaysof audit records were made through the use of untrusted software itwould be possible for malicious untrusted software to misrepresent theseaudit records to hide suspicious activities.

To overcome these problems, prior-art systems have developed a conceptknown as a “trusted path.” A trusted path is a mechanism by which theuser can communicate directly with the TCB. A trusted path may only beactivated by the user or the TCB and cannot be imitated by untrustedcode. Such a trusted path is a positive TCB-to-user connection thatbypasses all untrusted software. The Orange Book requires a trusted pathfor all systems to have a security rank of B2 or above.

A “trusted command” (also known as a trusted-path command) is a commandwhich requires a trusted path between the user and the TCB forexecution. The specific security policy of a computer system willdetermine which commands are defined as trusted commands. For example,commands relating to changes of the security levels of users would betrusted commands.

1.5 Parsers as Increasers of System Complexity

Because of perceived performance problems, prior-art computer systemsoften included code to implement certain functions in the TCB. One suchfunction comprises a portion of code known as the “parser.”

The parser performs the basic interpretation of user commands bytranslating a human-readable representation of a user command (e.g., acommand typed by a user at a keyboard) into a machine-readablerepresentation known as the binary representation, or the parsedcommand. A user command may consist of a group of words, typed by theuser, specifying some action to be taken. The user command may alsospecify one or more variations or options of that action.

For the convenience of the user, most parsers allow these option wordsto be typed in any order without changing the meaning of the usercommand. Also, most parsers allow the user to type the words in eitherfull or abbreviated form. In some instances, several possibleabbreviations exist. Further, in most parsers, the user may vary thespacing between the words without changing the meaning of the command.Some parsers also check user commands for proper syntax, and reporterrors to the user prior to execution of the command. Other parsersprompt the user for missing information, avoiding the need to completelyretype an incomplete command.

Thus, several different inputted human-readable representations may beassociated with each unique parsed command. It is the job of the parserto translate accurately these inputted representations of user commands(which may vary with each user) into specific parsed commandrepresentations. Due to the complex nature of parsing, large amounts ofcomputer code are generally associated with this activity.

Prior-art trusted software systems have included the parser for trustedcommands, and thus the associated code, within the TCB. In these systemsevery trusted command was parsed and executed exclusively by trustedcode. The inclusion of the parsing code in the TCB was regarded asnecessary for proper system operation.

As discussed above, however, the ease and degree of assuring a system isroughly inversely proportional to the complexity of the system's TCB.Thus, the inclusion of the parser in the TCB results in more complexassurance analysis and a corresponding decrease in system confidence.Prior art devices (since they needed to be small and simple to supportassurance) have thereby inherently constrained the user-friendliness ofcomputer systems.

2. SUMMARY OF THE INVENTION

The present invention provides a number of advantages over the priorart. By reducing the complexity of the TCB, the amount of trusted codethat must be verified or assured is reduced. In addition, the generalusability of the system is increased, because the improved method ofprocessing trusted commands allows for the implementation of addedcomputing functions at little or no additional cost in TCB assurance.

The present invention includes an improved method for the execution oftrusted commands. In this improved method, the required steps forprocessing a trusted command are split between trusted and untrustedcode. In this manner the amount of trusted code in the TCB may besignificantly reduced.

As discussed above, the parsing of a command can be comparativelydifficult, and often requires large amounts of complex code. However, itis relatively simple to translate the parsed representation of a commandinto a standard human-readable representation for display to the user.This is in part because a single, standard human-readable displayrepresentation may be associated with each parsed representation. Thepresent invention takes advantage of this fact by parsing the trustedcommands in untrusted code prior to execution in the TCB.

In general, the present invention includes a computer system whichincludes a TCB operating as a reference monitor. Included in the TCB isthe security-relevant code necessary for the actual execution of atrusted command.

Associated with the TCB are one or more untrusted subjects (e.g.processes). Each such subject has particular access rights, which mayinclude a security level. These untrusted subjects communicate only withthe involvement of the TCB. The TCB allows communication only aspermitted by the system's security policy. Each untrusted subject issubstantially independent.

In each of these untrusted subjects, untrusted software is generallyrun. This untrusted software may include an untrusted operating system(UOS), and generally includes applications such as text editors. In thepresent invention, the untrusted code includes the non-security relevantfunctions necessary for the execution of a trusted command.

Attached to the computer system are several user terminals. These userterminals allow the user to exchange information with the computersystem. All terminal activity is seen first by the TCB. Asecure-attention key is dedicated for use on each terminal attached tothe computer system. The TCB is designed to recognize and trap this keysignal. Activation of this key by the user establishes a trusted pathbetween the user terminal and the TCB. Alternate methods forestablishing a trusted path may be utilized.

The TCB is generally provided with a limited number of “direct” usercommands (direct commands). Because of this, the majority of the user'sactivities will take place in the untrusted operating system.

While operating in the UOS, the user may attempt to execute a trustedcommand. When one of these commands is issued by the user, the untrustedcode in the UOS checks the syntax of the command and may prompt formissing parameters; then the untrusted parser converts the command intoa parsed representation that will be referred to here for convenience asthe “binary representation.” In some instances, command procedures andapplication-issued trusted commands will also be parsed and translatedinto a binary representation.

This binary representation is then passed from the UOS to the TCB. TheTCB initially associates the binary representation with a physicalterminal, and copies the binary representation into a memory bufferassigned to that terminal.

Once this has been completed, the untrusted code in the UOS may promptthe user to activate the secure-attention key. If this key is activated,a trusted path will be established between the user terminal and theTCB. Alternate methods may be employed to initiate this trusted path. Arandomly generated process ID, which may be generated at login, may beutilized to prevent untrusted code from simulating a trusted path.

Subsequent activity by the TCB depends on the type of command that isrepresented by the binary representation. If the command is one thatwill not modify any information, i.e., a request to view information,the TCB verifies that the user has the necessary access rights, andattempts to execute the binary representation. A human-readable standardrepresentation of the binary command received by the TCB is displayedalong with the information.

In most instances, if the command requested by the user requestsmodification of information, the TCB displays for confirmation astandard human-readable form of the command, along with an indication ofwhat the result of command execution will be. The user is then requestedto confirm (by typing a response via the trusted path) that thedisplayed command was received correctly and should be executed.

This confirmation allows the user to ensure that untrusted code has notperformed an unauthorized modification of the user's original command.Also, confirmation allows for the detection by the user of any errorsthat may have occurred during the parsing process. In situations wherethe binary representation represents a command procedure or anapplication-issued trusted command, the confirmation ensures that thecommand proposed by the untrusted software is acceptable to the user.

If the command is confirmed by the user, the TCB checks to ensure thatthe user has the necessary access rights to execute the command and, ifso, attempts to execute the command.

A distinct advantage of the present invention arises from the fact thatthe execution of a trusted command is split between trusted code anduntrusted code. The actual parsing of the command occurs in untrustedcode. The trusted code included in the TCB checks the parsed command forcorrectness and displays it to the user in human readable form. Thischecking and display of a parsed command requires substantially lesscode than is required to parse a command.

Thus, since the command parser is included in the untrusted code, theamount of trusted code in the TCB is minimized. This lowers thedifficulty of trusted system assurance, and increases the amount ofconfidence that may be placed in a system.

It is a further advantage of this invention that the user interface isseparate from the underlying functions performed by the TCB. This allowsfor implementation of alternate UOS-to-user interfaces without majormodification of the TCB. Further, the amount of time and effort todevelop such a command interface is reduced. A still further advantageis that more useability features may be provided without substantiallyincreasing the complexity of the TCB. Examples of such useabilityfeatures are command line editing and recall.

3. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the various levels within a computer system;

FIG. 2 illustrates various layers within the trusted computing base;

FIG. 3 illustrates a trusted path;

FIGS. 4A and 4B are flow diagrams representing a method for processingtrusted commands. Differences in box representation in these drawings isexplained below.

FIG. 5 illustrates one method of implementing the invention;

FIG. 6 is a flow diagram representing a method for verifying a trustedpath;

FIG. 7 is a state transition diagram of a further embodiment utilizingvarious command states.

4. DESCRIPTION OF SPECIFIC EMBODIMENTS

A specific embodiment of the present invention is described with respectto a computer which supports various user processes and may operate in amultiuser environment. As an illustration, an implementation inconnection with a VAX model computer, available from Digital EquipmentCorporation (DEC), is briefly described. It should be understood thatthe present invention may be readily applied to various types ofcomputer systems including PC networks, stand-alone multiuser computersystems, or single user computer systems, to name a few examples.

4.1 Overview of Software Architecture

FIG. 1 illustrates a preferred computing environment which is generallydesignated by the reference numeral 2. A trusted computing base (TCB) 10resides at the center of the computer system. The TCB 10 acts as areference monitor in that access to information is mediated by the TCB10.

In a general embodiment of the invention, the TCB 10 may be a securekernel residing under the general operating system of a computer system.In one embodiment, the TCB 10 comprises trusted code residing underneatha VMS or Ultrix system.

The TCB 10 enforces a security policy which identifies permissible modesof access between users or computer processes (subjects) and files,memory segments or other objects. Access to stored information ismediated by the TCB 10, so that the TCB 10 may determine whether aparticular user or untrusted subject can access particular information.In order for the TCB 10 to fulfill its protective function, it must takeinto account the three requirements discussed above: (1) completeness,(2) isolation, and (3) verifiability.

A more complete understanding of the TCB 10 may be obtained by referenceto FIG. 2. As is illustrated, the TCB 10 may comprise several distinctlayers. Each layer of the TCB 10 comprises trusted code. This trustedstatus is indicated by the security boundary 11. In one embodiment,layers of particular interest are the layers to be referred to as:secure server (SSVR) 12, Command Conveyor (CC) 14, and VTerm (VI) 16.

The TCB 10 includes the trusted code necessary to ensure compliance withthe Orange Book requirements. In alternate embodiments, the trusted codemay ensure compliance with different systems of security requirements.The TCB 10 also includes the code which actually executes the requestedtrusted command, as discussed below.

Each untrusted subject is generally supported by an untrusted process.This process may spend time in one of two “modes.” The first mode, inwhich the process usually runs, is known as a “user mode.” This mode isa restricted hardware state such as the VAX user mode that is known inthe art. This process may also spend time executing trusted code in anall-powerful hardware state. This state is represented by the VAX“kernel mode”, which is known in the art. This state may be triggered bya request by the untrusted subject of the security kernel. Such arequest may be made in a conventional manner and is commonly called a“kernel call.” This mode may also be triggered by asynchronous events(e.g. the completion of an Input/Output request previously made by theuntrusted subject).

In one embodiment, the TCB 10 also has one process associated with eachterminal that communicates with the user over the trusted path. Thisprocess is known in the art as an “execution thread.” In thisembodiment, each execution thread shares its address space with otherTCB execution threads. An advantage of such sharing is economy ofmachine resources. Full-blown processes, each with its own addressspace, would require far more machine resources than if such addressspace sharing is employed.

It is the CC 14 which provides the interprocess communication forpassing parsed commands between the processes that support the untrustedsubjects, and the processes within the TCB 10 that support the trustedpath.

The untrusted code may submit to the TCB 10 the parsed representation ofthe trusted command by making a kernel call. The kernel call causes theprocess supporting the untrusted subject to switch to the all-powerfulhardware state and to begin to execute trusted code designed to handlekernel calls. This trusted code recognizes the nature of the kernel calland calls the CC 14. The CC 14 then obtains and copies the binaryrepresentation of the trusted command into protected memory and puts itin a global data structure that supports the user process associatedwith the terminal in question.

The VT 16 layer includes the trusted code which monitors all terminalactivity and checks for activation of the secure-attention key. In oneparticular embodiment, the VT 16 layer also includes code which trackswhich physical terminal is associated with a particular user oruntrusted subject.

The specific manner of implementation of the above described activitieswill be apparent to one skilled in the art having the benefit of thisdisclosure.

Referring to FIGS. 1 and 3, “around” the TCB 10 is a general untrustedoperating system (UOS) 20. The UOS 20 generally comprises untrusted codeand may include a traditional operating system such as Ultrix or VMS.Alternate constructions are envisioned where the UOS 20 includes anyuntrusted code. It will be appreciated that the system may includeuntrusted code that is separate from TCB 10 and UOS 20.

Most user activity will occur in the UOS 20. In one embodiment, aspecific UOS 20 may run in each untrusted subject.

4.2 User Terminals and the Secure-Attention Key

Associated with the computer system are one or more user terminals 30.These terminals 30 may be conventional in construction, in that theyallow the user to exchange information with the computer system. Either“intelligent” or “dumb” terminals may be used. Examples of such dumbterminals are the well-known VT series 200 and 300 terminals. Theseterminals are available from Digital Equipment Corporation or itsauthorized dealers.

A particularly useful terminal includes control programming that isdesigned with security features in mind, such as is described in aco-pending U.S. patent application entitled “Method for SecuringTerminal and Terminal Apparatus for Use with the Method,” Ser. No.456,672, filed by Wei-Ming Hu, Clifford E. Kahn, Andrew H. Mason, andPeter A. Sichel on Dec. 26, 1989 and to be commonly assigned with thisapplication.

A keyboard is attached to each user terminal. Each keyboard includes akey employed as a secure-attention key. This key is utilized toestablish a trusted path between a user terminal and the TCB 10. In oneembodiment, the secure-attention key is an “out-of-band key” for the UOS20. It is desirable that the signal sent by the terminal upon activationof the secure-attention key is generally not utilized by theapplications running in the UOS 20. An out-of-band key is convenientsince it does not restrict the traditional number of user keys and thesignal is sent immediately, even if other I/O is pending. For example,the secure-attention key may be the BREAK key on the terminal keyboard.

In may terminals (such as the VT 2XX and VT 3XX families) locking of thekeyboard prevents the transmission of several key signals. In theseterminals, however, the BREAK key signal may be transmitted, even from alocked keyboard. Thus it is generally desirable to employ the BREAK keyas the secure-attention key. Also, the signal generated by activation ofthe BREAK key comes in ahead of other characters in the keyboard buffer.A further advantage of utilizing the BREAK key is that software runningin the UOS 20 cannot get the terminal to send that character.

4.3 The Trusted Path and Direct Commands

The TCB 10 generally operates as a reference monitor.

Upon initial login or at other times when the user is not connected to aprocess in the UOS 20 (e.g., an application program), the TCB 10responds to a comparatively limited series of “direct commands,” whichmay include a CONNECT command to connect to an untrusted subject. Whenthe user is connected to such an untrusted subject, the TCB 10 checksfor the secure-attention signal; if a signal other than thesecure-attention signal is received, the TCB 10 passes the signal to theconnected untrusted subject.

As discussed above, in one specific embodiment the trusted code in theVT layer 16 monitors all terminal activity. When the code in the VT 16notices that the BREAK key has been depressed, the SSVR is signaled in aconventional manner (such as by advancing an event count or activating aflag). Code in the SSVR 12 recognizes this signaling and establishes atrusted path between the user terminal and itself. In this manner, thesecure-attention key signal is trapped by the TCB 10.

In certain security environments, general security requirements mandatethat the TCB 10 make displays when a trusted path is established andexited by the user. In one embodiment, when a trusted path isestablished, the TCB 10 sends a reset command sequence to the physicaluser terminal 30 to assure that it is in a known state. This is done inpart to ensure that the information displayed to the user by the TCB 10is in the intended form, (e.g., correct font). A particularly usefulsequence of commands to implement the reset command sequence isdescribed in the aforementioned copending U.S. patent application by Huet at.

When the secure-attention key is activated, other than in connectionwith the issuance of a trusted command, the secure server 12 displays aparticular banner and prompt (for example: “SSVR>” together with theuser's process identifier, discussed below), to indicate that the useris conversing interactively with trusted code. If the secure-attentionkey was activated in connection with the issuance of a trusted command,the secure server 12 displays to the user some indication of what is tobe done, as discussed below.

When command execution is complete, or when the user establishes orreactivates a session with the UOS 20, the TCB 10 issues a message toinform the user that he/she is breaking the trusted path. When a sessionwith the TCB is complete, the memory in the physical terminal may becleared by the TCB. This is done to protect trusted information fromboth untrusted code and unclassified persons who may later use theterminal. A particularly advantageous method of clearing the terminalmemory is described in the aforementioned co-pending patent application.

The number of direct user commands available from the TCB 10 ispreferably limited to reduce the complexity of the TCB 10. Generally, acommand is direct if:

-   -   a. one needs the command when one is not connected to an        untrusted subject;    -   b. end users depend on the command's correct behavior for        security (e.g., LOGOUT); or    -   c. the command must be issued when no user process in the UOS 20        is running.

In most cases, the user will converse with the TCB 10 through the SSVR12. In one embodiment the user conversing with the SSVR 12 may berestricted to commands which allow him/her to establish (connect) or end(disconnect) a computing session in the general UOS 20. Further commandsmay be added, such as allowing the user to view the existing UOS 20sessions or change his or her password, but it is generally desirable tolimit the number of available commands in the TCB 10. It is furtherdesirable to ensure simplicity in the syntax of these direct commands.

The simple syntax of the direct commands, and the comparatively smallamounts of code necessary to interpret these commands, do notsubstantially increase the complexity of the TCB 10.

4.4 Login Processing by the TCB

To initiate a computing session in the illustrative UOS 20, the user mayfirst login to the computing environment through the SSVR 12. Toinitiate a login, the user activates the secure-attention key (orperforms some other action to gain the attention of the SSVR 12). Asdiscussed above, this establishes a trusted path between the userterminal and the TCB 10. Alternate embodiments are envisioned whereinother methods are employed to establish a trusted path.

Once a trusted path has been established, the SSVR 12 prompts the userfor his/her specific user name and password. The various layers in theTCB 10 perform well-known security checks to ensure that the user hasthe necessary access rights to login at the terminal. If the userpossesses the required access rights, a computing session is establishedin the SSVR 12.

At this time, the user's security information is stored by the TCB 10.The TCB 10 also stores in memory a unique identifier of the userprocess. This information is maintained in memory by the TCB 10 as longas the user has an active session.

4.5 Connection to Untrusted Process

Because the number of direct user commands in the TCB 10 is preferablylimited, the user will generally choose to establish a computing sessionwith an untrusted subject. Such an untrusted subject may includeapplication programs residing in the UOS 20.

In one specific embodiment, when the user establishes a computingsession in the UOS 20, the user's physical terminal 30 is associatedwith a virtual terminal of the UOS. The user converses with theuntrusted subject through a computing session within the UOS 20. Whensuch a connection with an untrusted subject is made, the VT layer 16 ofthe TCB 10 stores in memory which physical terminal 30 is associatedwith which virtual terminal in an untrusted subject. In this manner,trusted commands received from an untrusted subject may be attributed tothe actual user at the physical terminal 30. Once the user hasestablished a computing session within the UOS 20, normal computingactivities may be carried out.

A more detailed understanding of these activities may be obtainedthrough reference to FIGS. 4A and 4B. Activities indicated by heavilybordered blocks are performed by the TCB 10, or trusted code. Activitiesrepresented by lightly bordered blocks are performed by untrusted code.

In FIG. 4A, the user terminal is represented as having established acomputing session 100 within the general UOS 20. During the session, theuser may attempt to execute various commands. Utilities within the UOS20 determine whether the issued commands are trusted commands 50. If thecommand is not identified by the UOS 20 as a trusted command, the UOS 20attempts to perform the command at process 60. In these cases theoperation and existence of the TCB 10 may have little effect on thecommand's behavior as seen by the user.

4.6 The Process Identifier

In one embodiment, a process identifier (process ID) is associated witheach user process at the time of login. This process ID is apseudo-randomly generated alpha-numeric tag which is associated with theuser throughout his/her computing session.

The process ID is useful if the untrusted code can temporarily disableor delay the effect of activation of the secure-attention key. Forexample, untrusted code can send a reset command to some terminals.While these terminals are resetting, activation of the secure-attentionkey has no effect. Such a technique may allow untrusted code to trickthe user into thinking a trusted path had been established when it hadnot been. The process ID inhibits such trickery by allowing the user todistinguish between actual and emulated trusted paths.

When the user first logs in, he/she will not yet know the process ID andcannot detect a false trusted path. However, to simulate a logindialogue, untrusted code would have to guess when the user activated thesecure-attention key, or somehow detect the activation of the key eventhough the TCB could not detect it. Guessing the activation time isimpracticable, because users start login dialogues at their ownconvenience and give no advance signal to the TCB prior to activation ofthe secure-attention key. Detecting the secure-attention key even thoughthe TCB could not detect it would be possible only by causing the key toyield a signal different than the TCB expects. Methods to prevent suchan event are described in the co-pending application by Hu et al.,referenced above.

With some terminals, the untrusted code may be able to program theterminal so that the secure-attention key generates a signal that isrecognizable to the untrusted code, but not to the TCB. In these cases,generation of the process ID at the time of login would beunsatisfactory. Instead, the process ID may be generated prior to userlogin. For example, in these embodiments, the process ID may begenerated when the user is registered with the TCB 10 and stored inprotected memory. In this embodiment the user may be given a way ofchanging his/her process ID, just as the user can generally change theirpassword.

In one particular embodiment, when the user logs in the SSVR 12pseudo-randomly generates a process ID and assigns this ID to thespecific user at the physical terminal. Methods of generating pseudorandom identifiers are generally known in the art. In one embodiment,the random number initial seed is based on a hardware (as opposed to asoftware) event. The algorithm for generating successive random numbersshould be computationally difficult to invert.

This process ID is maintained in the TCB and is never provided tountrusted code. Thus, untrusted code in the general UOS 20 is preventedfrom discovering the specific process ID assigned to the user.

The user is responsible for noting and retaining his/her assignedprocess ID. To promote user retention the process ID may be generated asa pronounceable group of characters. Methods for such generatingpronounceable passwords are described in “A Random Word Generator”,MITRE Technical Report (MTR-3006), May, 1975, by Morrie Gasser.

The process ID is displayed to the user when a trusted path isestablished between the user terminal and the SSVR 12. Displaying the IDserves a useful security function as it inhibits untrusted code from“spoofing” the user. Absent the process ID it may be possible for anuntrusted subject to emulate the SSVR 12. An untrusted subject,emulating the SSVR 12, may be able to trick the user into divulgingsecurity-relevant information or otherwise compromising system security.

The process ID, known only to the user and the SSVR 12, inhibits thistype of “spoofing.” Before the user responds to an apparent SSVR 12request, he/she will first verify that the proper process ID isdisplayed. Since the process ID is known by only the user and the SSVR12, it is extremely difficult for an untrusted subject, ignorant of theprocess ID, to fool the user into believing that he/she is conversingwith the SSVR 12.

FIG. 6 illustrates a flow diagram of this process. When the userinitially logs into the computer system through the SSVR 12, a randomlygenerated process ID is assigned to the user. This activity isrepresented by process 310. In one embodiment, this process ID comprisesalphabetic characters and is pronounceable. The pronounceable naturepromotes user retention of the ID. The process ID is then stored intrusted memory by the SSVR 12 and displayed to the user by the SSVR 12at process 320.

During the course of the computing session, the TCB determines if theuser is operating through a trusted path. This activity occurs atprocess 330. If the TCB determines that a trusted path is notestablished, the process ID will not be displayed to the user. This isnoted at process 350.

The process ID is maintained in trusted code and memory, and isinaccessible to untrusted subjects. Each time a trusted path isestablished between the SSVR 12 and the user, the SSVR 12 displays theuser's process ID at process 340. By observing the displayed ID, theuser is assured that an actual trusted path has been established.

4.7 The Command Conveyor

As discussed above, the command conveyor (CC) 14 is a layer in the TCB10 which comprises part of the trusted code. The CC 14 is utilized toensure proper communication of trusted commands between the SSVR 12 andthe process supporting the untrusted subject. As discussed, such anuntrusted subject may include a UOS 20.

Associated with each physical terminal 30 is a command buffer. In someembodiments, a status code may be associated with each terminal. In astill other embodiments, one of five command states is also associatedwith each physical terminal. The command buffer is used to store thebinary representation of the trusted command. The status code may beemployed to provide the resulting execution status to the untrustedsubject. The command states generally comprise five possibilities:

-   -   (a) no command,    -   (b) command submitted,    -   (c) command in progress,    -   (d) ignore finish, and    -   (e) command done.

These states are used to indicate the various states that may beencountered in the execution of a trusted command. FIG. 7 is statetransition of the command states. A detailed explanation of these statesand the statuses may be obtained from the following discussion.

4.8 Distribution of Processing of Trusted Commands

As discussed above, the TCB 10 “recognizes” two categories of commands.For the purposes of this specification “commands” include userinstructions received through the use of command line interfaces, menuinterfaces, direct manipulation interfaces or the like.

The first category includes “direct commands” issued while the user isoperating in the SSVR 12 layer of the TCB 10, i.e., is interactivelyconversing with the TCB 10. As discussed above, it is desirable to limitthe number of direct commands available to the user. The execution andprocessing of these direct commands is carried out using traditionalmethods known in the art.

The second category includes “trusted commands.” These commands areissued by a user operating in a non-trusted computing environment, suchas in the general UOS 20. In one embodiment these trusted commands areissued by a user operating in an untrusted virtual machine. FIGS. 4A and4B illustrate the activity necessary to execute such a command.

If the user attempts to execute a trusted command, the parser residingin the general UOS 20 parses the trusted command string and converts itinto a binary representation at process 70. In parsing the command, theuntrusted code in the UOS 20 checks syntax and semantics, and promptsfor missing parameters. Parsing strategies are well known in the art andwill not be discussed herein.

From a security perspective, it is not required that the code in the UOS20 perform an accurate translation of the user's commands into a parsedrepresentation (binary representation). The confirmation mechanism,described below, is designed to catch such errors whether benign ormalevolent.

Following parsing of the command, a process supporting the UOS 20 issuesa call to the TCB, submitting to the TCB the identification of theterminal from which such command was issued, at process 80. In oneembodiment, the virtual terminal from which the command was issued issubmitted to the TCB. Such a call is processed by the CC 14 in the TCB10. The CC 14 then determines which trusted subject submitted thecommand and copies the parsed representation into protected memory atprocess 90. In one embodiment this determination is made by asking VTermto identify the physical terminal associated with the UOS's virtualterminal.

Such a submission of the binary representation will be successful onlyif the TCB 10 determines that the submitting terminal is connected to anactive process.

Normally, in embodiments utilizing the command states, the command stateof the submitting physical terminal is no command which indicates thatthere is no trusted command submitted by that physical terminal or inprogress. This state is represented by state 400 in FIG. 7. When thestate is no command the CC 14 saves the binary representation in thecommand buffer, and sets the physical terminal's state to commandsubmitted, represented by transition state 410. Otherwise, thesubmission fails.

When the untrusted subject running in untrusted code receives indicationfrom the TCB 10 that the command has been submitted, it requests theuser to activate the secure-attention key. In one embodiment, theuntrusted code in the UOS 20 will request that the user activate theBREAK key.

If the user activates a cancellation key, for example Ctrl-Y or Ctrl-C,instead of activating the secure-attention key, code in the general UOS20 may cancel the trusted command. This can be accomplished by theuntrusted code issuing a kernel call (i.e., a request by the untrustedsubject of the security kernel) and informing the CC 14 that the commandis to be aborted. If the CC 14 finds that the command has not been sentto the SSVR 12, the command is canceled. Similarly, if the user processin the UOS 20 is killed, the process rundown code may cancel the trustedcommand request. However, if the CC 14 finds that the command hasalready been sent it proceeds; because the user is already executing thecommand.

In embodiments employing command states, cancellation of the trustedcommand request results in the command state being changed from commandsubmitted to no command. This process is indicated in FIG. 7.

If the user attempts to establish a trusted path at the same time thetrusted command is sent to the TCB 10, then the TCB 10 must arbitrate;either of these requests may be processed first. If the secure-attentionsignal is processed first, the TCB 10 may defer the command submission,and a connection with the SSVR 12 is established. If the submission isprocessed first, then the user sees the confirmation screen as isdescribed below.

If, when prompted, the user activates the secure-attention key, atrusted path is established between the user's physical terminal 30 andthe SSVR 12 in the TCB 10. This configuration is illustrated by the darkline in FIG. 3. When the VT layer 16 detects the secure-attention(BREAK) key, it notifies the SSVR 12 which then establishes a trustedpath in the trusted path-supporting process associated with the user'sphysical terminal 30.

Once the trusted path is established, the TCB 10 maintains exclusivecontrol over the physical terminal 30. In one embodiment, untrusted codein the UOS 20 waits to be notified that the command has been completed.Thus, the user essentially bypasses the untrusted code, and conversesonly with trusted code. Thus, if the user's process in the general UOS20 is killed, or the user's process terminates, or the general UOS 20crashes, the trusted command may still be executed. The user will not beinformed of any of these activities until the trusted command has beencompleted or abandoned.

Following establishment of the trusted path, the security requirementsof the system require interaction between the user and the SSVR 12. Thisis necessary to execute commands which require the establishment of atrusted path. The Orange Book criteria, and/or the system's securitygoals, will determine which commands require this interaction as isgenerally discussed in Section 4.9 below.

The establishment of a trusted path in these instances is useful forseveral reasons. First, it allows the secure server to identify thespecific user issuing the command. Second, the trusted path allows theuser to review and approve (or reject) the requested action in a trustedfashion. This reduces the possibility of malicious untrusted softwarealtering a command request, and allows for the detection of parsingerrors.

FIG. 4B illustrates the activity occurring after control has passed tothe TCB 10. As discussed above, the TCB 10 first establishes a trustedpath at process 120. The TCB then checks to see if a trusted command hasbeen submitted by the user. Untrusted code may then wait for the commandto finish.

Once a trusted path has been established, the SSVR 12 will call the CC14 to return the binary representation at process 130. In oneembodiment, the CC 14 will first determine the command state of thephysical user terminal 30. In a still further embodiment if the commandstate is command submitted 410 (FIG. 7), the CC 14 will return to theSSVR 12 the binary representation, and change the command state tocommand in progress 420. If the state is no command 400 or command done430, the call will fail, and the SSVR 12 will display the SSVR prompt(SSVR>) to the user. An initial command state of command in progress 420or ignore finish 440 implies a bug in the SSVR 12 and may result in theCC 14 crashing the TCB 10.

In these embodiments, if the command state was command submitted 410,then the CC 14 will return to the SSVR 12 the binary representation ofthe requested command.

4.9 Display of Command to User

Once the parsed command has been returned to the SSVR 12, the SSVR 12will determine if the command requires confirmation at process 140 (FIG.4B). Confirmation should generally be required for commands whichrequest modification of information. Commands that do not alter theinformation, such as the viewing of information, should not generallyrequire confirmation. For purposes of confirmation, redirecting thedisplay into a file should be considered as viewing information.

The decision of whether a given command should require activation of thesecure-attention key to execute depends on the basic security policy ofthe system. In one embodiment, secure-attention trusted commands are amechanism for use by system managers, security managers, operators, andholders of special privileges.

Generally, a command which is not a direct command, is asecure-attention command if:

-   -   a. it modifies a security kernel database in a security-relevant        way; or    -   b. it displays information on which a systems manager, security        manager, or operator will base a security decision.

If the command is one that does not require confirmation the TCB 10enforces the system's security policy and determine if the user has thenecessary access rights to execute the command at process 145. If thisis the case the TCB 10 attempts to execute the binary representation atprocess 150. Since certain commands, e.g. commands that merely displayinformation, do not change the state of the system, user confirmation isnot required. There is no security problem in not confirming thesecommands since the system only allows users to view information to whichthey have access.

There are certain commands that change the state of the system may notrequire confirmation. Some commands may allow the user to turn on a fileto receive the user's redirected output. This files are sometimes knownin the art as “listing files.” Generally, the turning on of a listingfile is a confirmed command.

In situations where a listing file has been turned on (i.e., the outputis redirected into this file) commands which normally displayinformation may, by writing to the listing file, alter the state of thesystem. In these cases, confirmation of these commands is generally notrequired because the flow of information is constrained by the TCB'ssecurity rules.

When a command requesting the display of information is executed by theTCB 10, the SSVR 12 responds by displaying a complete representation ofthe requested command as well as the requested information, i.e. thestandard human-readable representation of the command. In oneembodiment, the SSVR 12 displays the function code, command modifiers,and command parameters all in unambiguous notation. If employed, theprocess ID may also be displayed.

Thus, if the user's command is improperly parsed, or modified in anunauthorized manner, the user will be able to observe the difference.This inhibits an untrusted subject from fooling a user into believingthat he or she is observing the results of a submitted command, when infact that command had actually been altered.

If the command requested is one for which confirmation is required, theSSVR 12 displays a standard human-readable representation of what isabout to be done to the user terminal at process 170. The coderepresenting each command should produce a different display, unless thecommands have the same effect. As previously discussed, the re-displayof the action that a binary representation will perform is less complexthan the parsing of the original command. This is in part because bydefinition there is only one standard human-readable representation foreach parsed command.

By parsing the command in untrusted code, and verifying the request intrusted code, the overall complexity of the TCB 10 is decreased. Thedisplay of “what is about to be done” may of course vary from onecommand to another.

If the command's purpose is to add a record to a database or create anobject, the display may contain what the new record will contain, orwhat the attributes of the object will be if the command is confirmed.

If a particular database or object is to be modified, the display mayshow what the updated data will look like, or what the attributes of theobject will be if the command is confirmed. For commands which remove anexisting object, or delete an existing file, the display may show therecord or object.

Generally, for both adding/creating and modifying, the data packetrepresenting the submitted command may contain fields for the objectsattributes, such as its name, its size and its protection. For each ofthese fields, the packet may also have a flag indicating whether thefield is meaningful. These flags indicating meaningful fields may beknow as “field selectors.”

In add/create commands, the TCB may supply default values for unselectedfields. In commands which modify a database entry or object, unselectedfields may retain their previous values.

To aid the user, the selected fields may be highlighted when displayedfor confirmation. Such highlighting may be accomplished by methods knownin the art (e.g., by using escape sequences that begin and end reversevideo). This highlighting draws the users attention to the fields thathave non-default or changed values and helps to protect the user fromtricks by untrusted code.

When an audit record is produced of the confirmation display via thesink (discussed below) the reverse-video escape sequences may bereplaced with dashes on the next line. Example:

-   -   Name:JOHN.DOE

This change permits the audit record to be properly displayed on a widevariety of devices, even simple line printers.

Alternative embodiments are envisioned in which the TCB checks eachfield's value: for add/create commands the fields that have non-defaultvalues are highlighted; and for modify commands the fields that arechanging are highlighted. This “field comparison” approach generallyresults in less highlighting.

Generally, for every command, every packet field is displayed on thescreen, except for fields ignored by the particular command.

In the cases when a database will not be modified, the display generatedby the SSVR 12 may express what action is to be done. In this manner,the possibility of an erroneous confirmation is reduced since the useris requested to confirm the results, not the command.

The SSVR 12 may also display a list of user protection attributes sothat the user knows what role he or she is exercising. The user isrequired to confirm explicitly (Yes or No) the action requested. In ageneral embodiment, the TCB 12 displays for confirmation the resultswhich would occur if the command is executed.

Generally, any information in the binary representation that isdisplayed is first validated. This information is checked once to ensurethat certain requirements are met, e.g., to ensure that the counts ofarray elements are within array bounds (since out-of-bounds conditionscould provide an opportunity for entry into the TCB by illicitsoftware).

Before displaying the contents of a packet containing the binaryrepresentation of the command, anything that could cause the formattingcode to malfunction may be validated. Generally, such candidates forvalidation could include anything used to index into something else.Specific examples include the PASCAL language's implementation ofvarying strings (a count followed by an array of characters; the countis checked to be less than or equal to the character array size), andnumbers that represent keywords (their value is checked before it isused to index into an array of keyword text strings). Further methods ofvalidation are well known in the art and will not be discussed herein.

In one embodiment, the replies that the user may make to theconfirmation prompt are “yes”, “no”, Ctrl-C, Ctrl-Y, or the BREAK key.No default responses exist in this embodiment. For each user response,the secure server may display a message restating the response. If theresponse was “yes” or “no”, the secure server 12 displays an indicationof the computing session in the UOS 20 when it is being be resumed aftercommand completion.

If, however, the user activates the Ctrl-Y, Ctrl-C or the BREAK key, thecommand will be aborted. In one embodiment, the CC then changes thecommand status code to negative. This may be done to inform thesubmitting process that the command has been aborted. In these cases adirect session with the SSVR 12 will be established at process 300. Inthese instances, the user must explicitly issue a resume command toreturn to the session in the UOS 20.

If the user confirms the results or command, by replying with “yes”, orif the command does not require confirmation, the TCB 10 enforces thesystem's security policy at process 145. At this process the TCB 10determines if the user has the necessary access privileges to performthe requested activity. If the user has the required access rights, theSSVR 12, along with other code in the TCB 10 attempts to execute thecommand in a conventional manner.

Upon attempted execution of the command, the SSVR 12 may inform the CC14 of the execution status. In some high-security situations, concernfor information flow from trusted to untrusted code will preventinforming the CC 14. The CC 14 may change the command status to indicatethe SSVR 12 response. In addition, in alternate embodiments, the CC 14changes the command state from command in progress 420 (FIG. 7) tocommand done 430. In these cases, the CC 14 notifies the submittinguntrusted subject by traditional methods (e.g., by advancing aneventcount for that process). The SSVR 12 then reestablishes theterminal connection with the computing session in the UOS 20 from whichthe command was executed.

In embodiments utilizing the status code, if the user responds with“no”, the secure server informs the session in the UOS 20 that thecommand was not executed (negative status code). If command states arealso employed, the SSVR 12 changes the command state to command done andre-establishes the user's session in the general UOS 20 at process 160.

If the trusted command requested by the user is a command which affectsone of the system databases, and the database record was changed by someother process or user between the time the confirmation display appearedand the current user confirmed the command, then the SSVR 12 displays amessage indicating that a change has been made and requestsreconfirmation. In this case, the SSVR 12 waits for a response as if itwere the first time the information was displayed.

To ensure that if two users attempt to modify the same element at thesame time, only one request is rejected, the TCB may utilize identifiersknown as “modification counts” (mod-counts).

Each element of key databases (or registries) may contain a modificationcount. This mod-count is advanced after each modification and thusidentifies how many modifications have been made to the databaseelement. Thus, when a user attempts to modify a database element, theSSVR 12 first obtains that database element's mod-count. After the userhas confirmed the request, the TCB 10 checks the mod-count in therequest against the current mod-count.

A different mod-count indicates that a change has been made to thedatabase element, and the user is asked to reconfirm the request sincethe result previously confirmed by the user is not what the result wouldactually be.

To deter malicious users or subjects from preventing the execution oftrusted commands, two measures may be taken. First, certain accessrights may be required to change certain database elements. Second, themod-count should not be advanced when a modification is requested thatdoes not change the database element. In this manner, attempts bymalicious subjects to prevent execution of a trusted command, by rapidlyand spuriously causing the mod-count to be incremented, will beinhibited.

Once activity in the SSVR 12 is completed, the user's session in thegeneral UOS 20 is reestablished. In one embodiment, this may beaccompanied by the CC 14 informing the untrusted subject of the statusof the submitted command. The untrusted code in the general UOS 20 thenwakes-up the untrusted process running in the UOS 20 at process 160. Inone embodiment, before the TCB 10 passes the user to the untrustedsubject, the SSVR 12 prompts the user to activate a carriage return.This step is necessary to inform the user that he/she is being placedinto an untrusted environment.

4.10 The SSVR as an Audit Recorder

In one embodiment, the SSVR 12 audits (i.e., creates an audit trail bywriting to an audit or log file) at the command level. For directcommands the SSVR 12 audits both the command line and the final statusof the command. For trusted commands (secure-attention commands), theSSVR 12 audits both the confirmation display and the final status of thecommand.

To record the confirmation displays, the SSVR 12 defines a portion ofmemory to store the strings of information sent by the SSVR 12 to theuser's terminal. In one embodiment, this portion of memory is known asthe “sink.” Only the strings that comprise the SSVR's confirmationscreens are placed in the sink.

Strings may be appended to the sink only when the sink is opened. Thesink is opened when the SSVR 12 begins to service a trusted command. Thesink may be closed after the user has responded to the confirmationprompt, or before the display of certain requested information. Theinformation stored in the sink does not include the user input to anyprompts.

The information stored in the sink is maintained for auditing purposesand may be utilized according to traditional auditing practices.

4.11 Confirmation by Others than the Submitting User

In some situations it may be desirable for users other than thesubmitting user to confirm a secure-attention command. Such a situationmay arise if there is a certain application or command file thatincludes a privileged command but is needed to be run by a large numberof users. In the cases where it may be impracticable to grant all of theusers the necessary access rights, it may be possible to grant one userthe necessary rights, and to allow him/her to confirm this command forthe other users.

Such non-submitting user confirmation may be accomplished by having thecode in the untrusted subject lie about which user is submitting thecommand. For example, the code in the UOS 20 may ensure that certaincommands are always sent to the TCB 10 as if they had been submitted bya selected user.

One purpose of this select user would be to confirm these certaincommands for the other users. After a non-select user submits one of thecertain commands, the selected user will be notified that there is asubmitted command waiting. The select user may then observe theconfirmation display. If the select user determines that the commandsubmitted was a legitimate command, he/she may confirm the command.Otherwise, the original users attempt to execute the command fails.

4.12 Implementation Approaches

The method for executing trusted commands described above may beimplemented through the use of appropriate software. The actual designand coding is a matter of routine for those skilled in the art havingthe benefit of this disclosure. Such a design will of course vary withthe hardware platform and other factors associated with the specificdesired implementation.

FIG. 5 illustrates one such method for implementing the presentinvention. A programmable machine comprises a central processing unit(CPU) 210, and an input/output (I/O) device 220. The I/O unit 220 iscapable of reading and transmitting stored programming instructions fromknown storage media 230. The CPU 210 is capable of processing theseinstructions and executing the programming steps represented on media230. Such systems are well known in the art and will not further bedescribed.

To implement the invention, the necessary programming steps are storedon storage media 230 by traditional methods. The storage media 230 isthen read by the I/O unit 220 and the programming instructions aretransmitted to the CPU 210. The CPU 210 reads and interprets theinstructions, and may thereafter carry out the method of the invention.

1-20. (canceled)
 21. A computing environment configured to process atrusted command, comprising: an untrusted environment to parse a trustedcommand in order to establish a parsed trusted command, said trustedcommand only being executable in a trusted environment; and a trustedenvironment to receive the parsed trusted command from the untrustedenvironment and to communicate a representation of the parsed trustedcommand.
 22. The computing environment of claim 21, wherein the trustedenvironment executes the trusted command if the trusted environmentdetects confirmation of the trusted command.
 23. The computingenvironment of claim 21, wherein the representation of the trustedcommand is communicated through a trusted path.
 24. The computingenvironment of claim 23, wherein the trusted path is between a user andthe trusted environment.
 25. The computing environment of claim 21,further comprising: a user interface to communicate with the untrustedenvironment and the trusted environment.
 26. A method of processing atrusted command, said trusted command only being executable in a trustedmode, comprising the steps of: parsing a trusted command in an untrustedmode of a system; then establishing a trusted mode of the system; andthen communicating a representation of the trusted command in thetrusted mode.
 27. The method of claim 26, further comprising the stepof: executing the trusted command in the trusted mode if confirmation ofthe trusted command is detected.
 28. The method of claim 26, wherein thecommunicating step comprises the step of: displaying a representation ofthe trusted command.
 29. A method of processing a trusted command,comprising the steps of: interpreting a trusted command in an untrustedmode; communicating a representation of the trusted command in a trustedmode; verifying the trusted command in the trusted mode after thecommunicating step; and executing the trusted command in the trustedmode after the verifying step.
 30. The method of claim 29, wherein theverifying step comprises the step of: requesting confirmation of thetrusted command in the trusted mode.
 31. The method of claim 29, furthercomprising the step of: using the trusted command in the untrusted mode.32. The method of claim 29, further comprising the step of:transitioning from the untrusted mode to the trusted mode.
 33. Themethod of claim 29, further comprising the step of: transitioning fromthe trusted mode to the untrusted mode.
 34. The method of claim 33,further comprising the step of: issuing a message to a user to indicatea transition to the untrusted mode before the transitioning step. 35.The method of claim 29, further comprising the step of: detecting if acommand is a trusted command in an untrusted mode.